Definitely want your thoughts on this @tomchristie

Ping @tomchristie I think this interface is really promising.

I'm still not really sure at the moment. There's a couple different styles we could use, one is a separate process_request -> request and process_response -> [request|response] like this.

Another option would be a single callable or method, that is passed a request, and the next callable...

async def middleware(request, call_next):
    # Do some request processing
    response = await call_next(request)
    # Do some response processing

I think it's a bit awkward that we're having to set up a middleware chain per-request.

The other thing that ties in here is our existing dispatch interface. The auth and redirect implementations here could alternately be treated as dispatch subclasses, that are provided with the next dispatcher in the chain (and are each setup once per client rather than on every request.)

I'd probably need to make a separate PR to show how that'd look, and why it ties in to me now being sure exactly what we should (or shouldn't) do about a middleware interface.

Apologies for not being able to be more definitive yet.
It's a really nice piece of work, but I'm having a hard time figuring if it's the right direction or not.

No worries, that's why I put together this PR, so we can think about it and discuss it. 🙂

I think it's a bit awkward that we're having to set up a middleware chain per-request.

I agree. The reason it's that way is because we allow auth to be passed as arguments to the initializer of Client and also to Client.send. We also have a max_redirects argument to the Client initializer but a allow_redirects flag in Client.send.

Ideally we'd build the necessary middlewares once on the initializer, but we'd have to break the send API to do it, which I personally don't think it's worth it but maybe it is?

The other thing that ties in here is our existing dispatch interface. The auth and redirect implementations here could alternately be treated as dispatch subclasses, that are provided with the next dispatcher in the chain (and are each setup once per client rather than on every request.)

That's interesting, we would avoid introducing a new abstraction at the cost of building the chain from the set of arguments.

I think I'll have a go at this and open up a different PR from what's on this one.

Closed in favor of #268